fix: zera os vermelhos conhecidos do differential (12/13) e fixa o oráculo no primary - #14

Fecha 12 dos 13 vermelhos conhecidos do differential. O 13º (2794) fica com diagnóstico completo: não é bug, é uma porta de backend que falta.

A descoberta que organiza metade do trabalho

Seis dos treze não eram regressão do scriptc — era o oráculo seguindo o HOST. As três lanes de differential ainda resolviam o oráculo com nodeOracleExecutable(), que segue o host, e esta máquina roda Node 26. O .node-version do repositório fixa 24.15.0, que é também o primary do NODE_COMPAT_MATRIX — ou seja, esses seis só ficam vermelhos numa máquina que roda um Node diferente do que o repositório fixa.

O node-matrix.ts que acabou de entrar já descreve exatamente essa distinção, e a docstring dele diz o que fazer: um censo segue o host, mas um oráculo SEMÂNTICO fixa no primary, porque um binário compilado reproduz o comportamento observável de UM Node e não consegue reproduzir dois. A infra entrou; as lanes de differential é que ainda não tinham sido migradas.

Migrar as três (primaryOracleExecutable(NODE_COMPAT_MATRIX)) faz os seis passarem sem tocar em nenhuma fixture, e faz uma execução local reproduzir o oráculo do CI em vez de depender do Node que estiver instalado.

Cheguei primeiro pelo caminho errado — normalizei as seis fixtures para serem estáveis nos dois majors — e refiz depois de ler o node-matrix: aquela abordagem apagava justamente a metade version-dependent de cada asserção, que é o que fixa a semântica do primary. Fixar o oráculo preserva a cobertura inteira, e SCRIPTC_NODE_ORACLE continua sobrescrevendo — que é como se vai ATRÁS dessas divergências de propósito, em vez de tropeçar nelas.

Confirmado empiricamente em origin/main limpo, sem nenhuma mudança minha, com o oráculo no primary: exatamente esses seis passam, exatamente os seis bugs reais continuam falhando.

Tabela: fixture → causa-raiz → veredito

Os bugs reais

ABI do islandRest (2568, 2590) — o mais grave. Uma assinatura island-rest SOletra seu parâmetro final (array do engine) na lista de params e é marcada rest. O thunk de chamada boxed lia as duas coisas literalmente: preenchia todo param posicionalmente — entregando ao slot final o primeiro argumento EXCEDENTE onde a closure espera o pacote — e ainda anexava um array dyn extra que o callee não tem parâmetro para receber. const f = (...args) => args.length; f(1, 2) num programa --dynamic estourava com expected number, got undefined, porque args era o número 1: uma arrow no topo do módulo é um global dyn, então a chamada passa por esse thunk e não pelo caminho direto. Todo idioma de rest-forwarding sob --dynamic quebrava assim. Corrigido no emissor C e no LLVM (o Rust já fatiava certo); 2859-island-rest-boxed-call.js fixa a ABI de forma mínima nas três lanes.

.finally sobre promise dyn (2210). O resultado do callback era descartado — atalho documentado no próprio código ("that refinement waits for a use"). Uma cleanup que REJEITA nunca chegava à cadeia: escapava da fiber de reação e o binário morria com unhandled rejection, onde o JS substitui a settlement. E não esperar uma cleanup que RESOLVE settlava a cadeia cedo demais, o que era a causa real de finally kept 7 passar na frente de finally ran — a ordem era sintoma do mesmo await faltando.

Web globals da island (1120). formDecode andava por CODE UNIT do UTF-16 e entregava surrogates soltos ao TextEncoder, então astral virava dois U+FFFD antes de chegar ao toString(); entries/keys/values/forEach tiravam snapshot, quando a iteração de pares do WebIDL é VIVA (índice posicional relendo a lista atual — as quatro escadas de mutação estavam erradas, forEach incluído); e btoa/atob lançavam Error carimbado em vez do DOMException que o próprio prelúdio já define. Nada sob vendor/ foi tocado — a política do vendor README proíbe, e o libqjs.a é cacheado por commit upstream.

optChain island → union (2716). O braço jsval do emissor LLVM só tinha resultado void e resultado do engine, e lançava InternalCompilerError no resto. Um passo que aterrissa de volta no mundo ESTÁTICO (flatValue(...)?.trim()) responde string | undefined. Ganhou as mesmas duas formas que o emissor C já tinha; um kind não modelado agora vira LlvmUnsupportedError em vez de alegar bug do emissor.

write(string, encoding) em socket (2599). Só três formas eram lowered; qualquer outra encoding literal caía na cerca "write with 2 arguments" e o programa nem compilava. Uma encoding que o Node não conhece agora é o ERR_UNKNOWN_ENCODING síncrono dele. Spellings conhecidas mas ainda não lowered (hex, base64) mantêm a cerca em vez de escrever bytes errados. A fixture ganhou um degrau para isso ao lado do 'buffer', que fica.

2084 é divergência de motor, não bug: o erro é lançado dentro do quickjs-ng, que escreve not a number onde o V8 escreve Number.prototype.toFixed requires that 'this' be a Number. O vendor não é nosso para alinhar, então a fixture passa a fixar o TIPO do erro (que é o contrato real) e a limitação está escrita nos dynamic-tier limits.

Estado do gate: 13 vermelhos herdados do main

O differential C completo termina com 14 falhas: 2794 (acima) e 13 que já estão vermelhas no main, todas verificadas em origin/main limpo, sem nenhuma mudança minha, contra o Node que o repositório fixa.

Sete regridem em e313ba28. Bisect com build + differential em cada ponto:

São 1559-conditional-spread-index-merge, 1562-optional-chain-tails, 1575-unknown-assert-into-record, 1576-width-coercions, 2047-objlit-accessors-shapes, 2464-qs-require-forms e 2678-util-parseargs. O sintoma é sempre leitura de propriedade virando undefined (app: dev 5173 → app: none 0; 127.0.0.1 3000 yes → undefined undefined undefined). Não é sensibilidade de versão: falham também com o oráculo no primary. e313ba28 mexeu em lowering do frontend (lower-calls.ts, lower-exprs.ts, lower-island-interface.ts) numa feature mirada no Rust e regrediu a lane C de referência.

Quatro são de tuplas/destructuring: 540-tuples-basics, 1432-destructured-params, 1572-promise-reject-all-tuple, 2575-string-destructuring-decl. Falham nos dois oráculos, e no main atual sem nada meu.

Duas são de stream, e valem uma olhada à parte: 2845-readable-paused-read-boundaries e 2846-readable-unshift-order falham contra o primary — e passam contra Node 26. Elas fixam a semântica NOVA do read(): depois de read(3) devolver hel, o read() seguinte responde lo (só o resto do primeiro chunk) em vez do lo world que o Node 24 concatena. Isso expõe uma incoerência interna do runtime: o async-iterator concatena (semântica pré-26, o que 1746/2813 fixam) enquanto o read() pausado devolve um chunk por vez (semântica 26). As duas já estão vermelhas contra o Node que o repositório fixa; o oráculo seguindo o host é que escondia isso. Não mexi — escolher qual das duas semânticas o runtime implementa é decisão de vocês, e é a mesma decisão do follow-up abaixo.

Nenhum desses 13 é regressão deste PR.

Issue: portar rl.nextLine para o runtime C

2794 não é regressão — é cobertura de backend faltando, e o emissor C já declara isso no código ("The native async-iterator slice currently belongs to the Rust runtime"). for await (const line of rl) baixa para o libCall rl.nextLine (Promise<string | undefined>), implementado só em backend/rust/readline.ts. A lane LLVM falha pelo mesmo erro porque cai no fallback C — então uma implementação em C resolve as duas lanes.

O que falta:

1. packages/runtime/src/scr_readline.c — o slot de callback pendente de question tem quase a forma certa, mas falta o modo "próxima linha OU fim": hoje scr_rl_settle_close DESCARTA um callback pendente (a question do Node nunca responde), enquanto nextLine precisa resolver undefined no fim do stdin, e resolver de novo em toda chamada seguinte para o laço for await terminar. Uma linha já bufferizada tem de responder na hora, como question faz via scr_rl_drain.
2. packages/compiler/src/backend/emission/emit-exprs.ts — o caso rl.nextLine cria scr_promise_new() e passa um adaptador internado por union que monta string | undefined e cumpre a promise. O precedente exato já existe: scr_promise_race_add(result, p, &adapter) com E.raceAdapterFor.

O risco não é o tamanho, é a corretude assíncrona: manter o event loop vivo enquanto um nextLine está pendente, resolver undefined exatamente uma vez no EOF, e crlfDelay: Infinity. Preferi deixar diagnosticado a entregar meia implementação de I/O assíncrono.

Follow-up: decidir a semântica de read()

O read() sem size concatena o buffer inteiro no caminho do async-iterator — semântica pré-26, e a que a documentação do Node ainda descreve — mas o caminho pausado devolve um chunk por vez, semântica da #60441. Como o binário reproduz UM Node, essa divisão é um bug em si, independente de qual lado se escolha: 1746/2813 fixam um lado e 2845/2846 o outro.

Gates

🤖 Generated with Claude Code

https://claude.ai/code/session_01Bab3v6PNzMBUq7nJhLR8i7